Communication networks continue to evolve with the introduction and application of packet-switched networks composed of internet protocol (IP) devices that switch packets of data. Such networks are often used to implement voice over IP (VoIP) as opposed to the traditional time division multiplexed (TDM) communication implementations typically carried over a circuit-switched network. With the introduction and prevalence of packet-switched networks, interfaces between the traditional circuit-switched networks and packet-switched networks have become an important part of communication network infrastructure. These interfaces are often controlled with a softswitch, which is responsible for controlling interface devices that process media such as by providing conversion services between circuit-switched and packet-switched infrastructures. In a packet-switched network, call signaling functions are typically implemented with the session initiation protocol (SIP) or the H.323 protocol. SIP has become widely adopted for use in establishing, modifying and clearing communication sessions in packet-switched networks including IP-based networks. In some such IP-based networks, softswitches use SIP to facilitate session processing, typically within a network domain that may be interconnected with other domains serviced by corresponding softswitches. Signaling messages for processing sessions thus typically cross domain boundaries, but can carry information related to a specific domain that an operator may not wish to expose.
Referring to FIG. 1, a conventional IP network 100 is illustrated, showing interconnections between different network domains 102, 104 and 106. The borders of network domains 102, 104 and 106 include session border controllers (SBCs) 110-113 that operate to provide protection and security for internal systems of network domains 102, 104 and 106. The signaling messages exchanged between network domains 102 and 104 and between network domains 104 and 106 pass through respective pairs of SBCs 110, 111 and 112, 113 and tend to carry information related to the structure of network domains 102, 104 and 106. Such topology transparency that shows the internal structure of the network implementing each of network domains 102, 104 and 106 is often undesirable as posing a security risk.
Referring now to FIG. 2, a conventional SBC 200 is located at a boundary of a private inner IP network 204 and a public, or outer IP network 205. SBC 200 can intercept signaling 202 and media 203, and may take the form of a back to back user agent (B2BUA), which employs separate dialogs on either side, i.e., with respective networks 204 and 205, to implement a communication session. The B2BUA configuration operates to terminate each of the dialogs and provides services such as routing between the dialogs to implement the communication session. In some instances, an SBC is configured as a proxy, which is intended to route session messages with a high degree of transparency, meaning that the messages are as unchanged as possible while still accomplishing the proxy function of routing.
Referring now to FIG. 3, the configuration and operation of a conventional SBC 300 is illustrated. SBC 300 handles access and interconnect traffic through the various interfaces 310-315. Interfaces 310-315 have attributes or properties related to protocol (SIP or H.323), IP address and port, and transport type, such as UDP or TCP. SBC 300 employs functional entities for routing including interconnect border control function (IBCF) routing and proxy call session control function (P-CSCF) routing. These functional entities contribute to performing routing in SBC 300 for messages involved in various sessions and dialogs among the various network entities.
Referring to FIG. 4, an exemplary SIP message processed by SBC 300 is illustrated. An incoming SIP message 310 is described as being received at SBC 300 as an ingress message, while SIP message 312 is described as being sent from SBC 300 as an egress message. SIP message 310 includes various information items identified as I1-I5, which may correspond to headers or content information of SIP message 310. SBC 300 receives SIP message 310 and implements control on the content of SIP message 310 to perform security functions, for example. SBC 300 typically inspects information items I1-I5 and determines whether to pass, modify or drop any of information items I1-I5. As can be seen by the content of egress SIP message 312, information items I1 and I4 are dropped, while information 13 is modified and information items I2 and I5 are passed without change.
The information items I1 and I4 being dropped from egress SIP message 312 may represent certain identification information that an operator of SBC 300 may not generally wish to pass. Sometimes, identification information is used to provide assurance for a trusted entity to implement a form of security. Identification information may sometimes also be used to identify a party, such as a carrier, to permit certain communication activities to occur on a more secure basis. However, when SBC 300 is configured with a direct, static setting for dropping information items I1 and I4, the functions associated with the dropped identification information may not be possible.
Referring now to FIG. 5, a diagram 500 illustrates operation of SBC 300 involved in a session between Peer A 510 and Peer B 512. Diagram 500 illustrates a SIP session initiated with an invite request from Peer A 510. Diagram 500 shows the typical sequence of events for request/response activities with respect to each of Peer A 510 and Peer B 512. For example, SBC 300 passes invite request 520 from Peer A 510 to Peer B 512, but initiates a response with identifier “100” to Peer A 510 and absorbs or terminates a response with identifier “100” from Peer B 512. Each of the messages that are passed by SBC 300 between Peer A 510 and Peer B 512 may be subject to transparency-related modifications to implement security functions or to achieve other behavior related to border operations between two domains.
Due to the nature of cross-border communications between network domains, it can be challenging to implement a consistent transparency control that achieves the goals of the operator. Conventional systems tend to be limited to unconditionally hiding or controlling transparency for specific information such as topology due to the limitations of the SBC modeled as a B2BUA. In addition, specific workarounds for transparency to achieve desired information exposure across boundaries can be complex and may lead to operational challenges in implementing a desired level of transparency on the part of the operator. Moreover, conventional transparency control is not easily used to accommodate changing situations, such as, for example where messages related to a given session are re-routed to a new peer and/or interface.